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type experience. The data transfer between the 
email application program and the email server is 
handled by the present invention in the background. 
On the server end of the connection, the invention 
operates to spoof the server and thus causes the 
server to operate as though the remote customer is an 
interactive user presendy connected to the domain. 
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A SYSTEM AND A METHOD FOR ACCELERATING COMMUNICATION 
BETWEEN A CLIENT AND AN EMAIL SERVER 

CROSS-REFERENCE TO RELATED APPLICATION 
5 This application claims the priority of U.S. Provisional Patent Application No. 

60/346,683 filed January 06, 2002, entitled «A SYSTEM AND A METHOD FOR 
ACCELERATING COMMUNICATION BETWEEN CLIENT AND MS EXCHANGE 
SERVER" the subject matter of which is hereby incorporated by reference. 

10 TECHNICAL FIELD 

The present invention relates to the field of data communications and, more 
specifically, to the enhancement of transferring data throughput in communication system 
between an Email Server and a client utilizing Email software. 

15 BACKGROUND OF THE INVENTION 

Historically, in server based networks serving one or more clients, the servers have 
utilized powerful computers while the client computers have utilized computers possessing 
lunited computing power and limited storage capacity. Generally, communication between 
the clients and the servers has been enabled through the use of a LAN (Local Area Network) 

20 using a high capacity conununication link and generating a domain. 

A domain is a group of computers and devices on a network that are administered as a 
unit with common rules and procedwes. Within the Internet, domains are defined by the IP 
address that is assigned. All devices sharing a common part of the IP address are said to be in 
tiie same domain. 
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Therefore, in client/server architectures, the store^e and the processing is primarily 
performed on the server side while the client computer operates as a terminal and an interface 
unit between the user and the server. Obviously, this type of an architecture results in heavy 
transportation of mformation between the client and the server. It should be noted that the 
toms "client" and "user" are used interchangeably herein. 

In recent years, the portable computer has expwienced explosive growth in utilization, 
as well as in the performance capabilities, features, processing power, memory availability 
and capabilities. There has also been a great deal of expansion in use and availability of the 
global data communication network known as the Internet, and the use of portable 
communication systems like, but not limited to, cellular or satellite systeans. 

It is desirable for an enterprise lhat is ushxg a client/servM architecture, for example 
MICROSOFT OUTLOOK and the MS exchange server, to provide users with the ability to 
access their MS Office documents and E-mail messages while bemg out of the office and 
connected through the Internet via telephone lines or a wireless network, like but not limited 
to Cellular or SatelUte networks. Outlook is MicrosofPs mail client and personal information 
manager. The foil version includes a PIM (Personal Information Manager) calendaring, to-do 
list and groupware functions. OUTLOOK also provides a joumaling capability for keeping 
track of hourly billing. OUTLOOK can be used as the client end to MICROSOFT'S 
Exchange Server or as the e-mail client with any ISP (hitemet Service Provider) account. The 
paragraphs that follow refer to an MS exchange server as an example of an Email Server of 
the present mvention, and to OUTLOOK as an example of an Email application. 

One technical hurdle, m meeting this desire, is that the wireless communication 
systems or networks have a lunited bandwidth. Using such lunited bandwidth networks to 
replace a LAN results in mcreasmg the communication time between the remote users and 
reduces the quality of the connection. 

Therefore there is a need m the art for a system and a method that can reduce the 
transportation between a remote user and a server in an on-line operation. Such a system can 
increase the speed of the communication. FurthCT, there is a need in the art for a system and 
method to reduce the transportation between a remote user and a server over a wureless 
communication channel. 

A specific example of tiiis need can be seen m tiie setting of a user mailbox within an 
exchange server. In tiiis setting, tiie user mailbox is part of tiie exchange server information 
store. The information store consists of three implonentations of MAPI message stores: the 
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public information store, the private information store, and the personal folder store (PST). 
MAPI is an abbreviation of Messaging Application Programming Interface, a system built 
into Microsoft Windows that enables different e-mail applications to work together to 
distribute mail. As long as both applications are MAPI-enabled, they can share mail 
messages with each other. The paragraphs that follow refer to MAPI as an example of an 
application programmuig interfece of the present invention. 

Hie information store organization of public folders, private folders, and messages is 
referred to as tiie organization hierarchy. Another implementation of a MAPI message store 
is configured when a user works offline or not connected to the exchange server. This 
message store is caUed the offline folder store (OST) and the content and structure of the OST 
mirrors fee mailbox while offline. 

A mailbox is the delivery location for all incoming mail messages addressed to a 
designated owner. Information in a user's mailbox is stored in the private information store 
on a Microsoft Exchange Server computer. A mailbox can contain received messages, 
message attadunents, folders, folder hierarchy, and more. 

OUTLOOK uses MAPI over Remote Procedure Calls (RPC) as it's transport provider 
to connect the user to its mailbox that resides physically at the exchange server as part of the 
information store. RPC is a call that is based on a client server model. Procedures that are 
called within the client application are actually performed withm the server side over a 
communication channels. The MAPI transport provider and the MAPI message store, called 
the exchange server service, are tightly coupled in such a way, that it is impossible to use only 
the MAPI message store and a different transport provider and still maintain the provision of 
all the services the Exchange server service offers. 

Using RPC as the communication between a remote user and its mailbox at the 
exchange server over low bandwidth is very slow and has a lot of communication overhead. 
When the user uses OUTLOOK in the offline mode, outgoing messages are kept in the user 
outbox in its offline folders, and incoming messages are kept for him at the exchange server. 
When the user is gomg back onlme, the exchange server and outlook synchronize those 
messages. This process results in a significant amount of data transfer to occur, depending on 
the amount of traffic received and the time that the user has been off line. In a wureless 
configuration, this process can absorb a significant percaitage of the available bandwidth. 
Thus, there is a need in the art for a method to reduce the transportation between a remote 
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user and a server in an on-line operation when large amounts of data, such as during a 
synchronization function, is necessary. 

SUMMARY OF THE INVENTION 



The present invention provides a system and a method that improves the on-line 
operation between a remote email or application program and the exchange server to which it 
interfeces, such as a mailbox exchange server. The present invention operates by tricking or 
controlling the email application program in such away that the email application program 

10 opemtes as it is on-line although it is off-line. In an embodiment of the present invention, this 
is accomplished by spoofing the OUTLOOK application program and as a result, the 
OUTLOOK system operates off-line but the user has on-line type experience. 

More specifically, the present invention replaces the MAPMIPC as the transport 
provider while the user is operating tiie email application program in an off-line mode. The 

15 data transfer between the email application program and the email server is handled by the 
present mvention in the background. On the server end of the connection, the present 
invention operates to spoof the server and thus causes the server to operate as though the 
remote customer is an interactive user presently connected to the domain. 



20 machine to overcome the MAPI session limitation of an Exchange Server. The Exchange 
Server operates to enable only a limited number of MAPI sessions per interactive user's 
computer. The present invention overcomes this limitation by generating a separate task for 
each active remote user (a User Agent (UA)). This method of spoofing the Exchange Server 
enables the Exchange server to support a plurality of remote users via a single NTAVin2000 
25 machine or equivalents. 

An exemplary embodiment of present invention may include, but is not limited to, 
two logical modules that work within the client/server architecture: 

(1) A Domain Logical Module (DM), which is installed on an NT machine or 
similar machine and has a computer account in the domain; and 
30 (2) A Client Logical Module (CM), which is mstalled in the client's computer as 

an extension of the mail program. 

The present invention may be a DLL OUTLOOK extension/add-in, and replaces the 
MAPI/CDO as the transport provider. CDO, or Collaboration Data Objects is a technology 



5 



Another aspect of the present invention is using the multi-tasking feature of an NT 
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for building messaging or collaboration applications. DLL is short for Dynamic Link Library, 
a library of executable functions or data that can be used by a Windows application. 
Typically, a DLL provides one or more particular functions and a program accesses the 
functions by creating either a static or dynamic link to the DLL. A static link remains 

5 constant during program execution while a dynamic link is created by the program as needed. 
DLLs can also contain just data. DLL files usually end with the extension ".dll". 
A DLL can be used by several applications at the same time. Some DLLs are provided with 
the Windows operating system and available for any Windows application. Other DLLs are 
written for a particular ^plication and are loaded with the application as in the exemplary 

1 0 embodiment of the present invention. 

CDO is the bridge from Visual Basic and scriptmg languages to MAPI. CDO exposes 
COM objects, but these COM objects are of the right nature to be accessible tiirough both 
languages. 

The present invention may be used in conjunction with an additional system, which 
15 operates to accelerate the communication over a problematic network channel such as, but not 
limited to cellular, satellite or other wireless channels. This additional system may operate to 
compress or otherwise modify the communication protocol to create a more eflBcient protocol 
or make other changes and adjustments. Examples of such additional systems include 
NettGain 1100 of Flash Networks. If the accelerating system is used, two additional modules 
20 may be needed - one in each end of the problematic line. However, it should be noted that 
these additional modules are not required elements of the present invention but rather, can be 
incorporated into tiie present invention. These additional modules include: 
Client Booster (C. BST). 
Gateway Booster (G. BST). 
25 The present invention supports substantially all OUTLOOK built-in forms, such as the 

E-mail messages, appointments, contacts, calendar, tasks etc. 

Other objects, features, and advantages of the present invention will become apparent 
upon reading the followmg detailed description of the embodiments with the accompanymg 
drawings and appended claims. 

30 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram illustrating a common environment in which an exemplary 
embodiment of the present invention may be used. 

Fig. 2a illustrates a block diagram of an exemplary embodiment of a Client Module 

5 (CM). 

Fig. 2b illustrates a block diagram of an exemplary embodiment of a Client Module 
(CM), which is connected to a booster module. 

Fig. 3 illustrates a block diagram of an exemplary embodiment of a Domain Module 
(DM) in a corporate domain. 
10 Fig. 4a and Fig. 4b are a flow chart illustration of a method implemented by an 

exemplary embodiment of the present invention during the login stage. Fig. 4a illustrates a 
method implemented by an exemplary embodiment of a Client Module and Fig. 4b illustrates 
a method implemented by an exemplary embodiment of a Domain Module. 

Fig. 5 illustrates a method implemented by an exemplary embodiment of a Client 
15 Module during on going operation after tiie Login stage. 

Fig. 6 illustrates a method implemented by an exemplary embodiment of 

a User Agent (UA) 360 during the on going operation, after tiie Logm stage. 

Fig. 7 illustrates a method unplemented by an exemplary embodiment of a UA 360 
during A Logoff stage. 

20 

DETAILED DESCRIPTION 

Referring now to the drawings, in which like numerals refer to like parts throughout 
the several views, exemplary embodiments of the present invention are described. 

Fig. 1 is a block diagram illustrating a common environment in which the present 
25 invention may be used. A cellular system 100 has been selected as an exemplary 
environment that is suitable for unplementing the present mvention. However, it should be 
noted, and readily observable to those skilled in the art, that the present invention is not 
limited to operation within a cellular environment, and for that matter, any other specific 
communications system. But rather, the present invention can be unplemented using various 
30 communication systems such as, but not limited to, satellites, the PSTN (Public Switched 
Telephone Network), ISDN (mtegrated services digital network) lines etc. 

A plurality of laptop computers 110a to llOn are connected via cellular connections 
120 to a gateway (GW) 130, which can be located in a particular cell or m an operator station. 
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The laptop computers 110 may represent any portable devices that use MAPI messages 
services for communicate with an exchange server, like but not limited to palm computers, 
cellular phones etc., and will collectively be referred to as client 110. 

The communication over connection channels 120 can be based on TCP/IP or, it can 
5 be based on a proprietary accelerating protocol. In case of using a proprietary accelerating 
protocol, two additional modules are needed (one for each end of the Ime 120). 

GW 130 may be coimected via a VWB (Very Wide Bandwidth) connection 140 to the 
Internet 150 and jfrom there, via the appropriate Domain Modules (DM), 160a to 160m, to the 
domain of each of the cooperates, 170a to 170m, which comprises the appropriate Exchange 
10 Server, 175a to 175m. 

More than one client llOmay be connected to the same domain 170 via the same DM 
160 and be engaged in an interactive connection with the same Exchange Server 175 
simultaneously. 



15 (CM). The CM 205 is a OUTLOOK extension DLL. The CM 205 operates to receive 
indications from OUTLOOK, or some other email application program, when a new message 
has been submitted to the outbox; change the message from the messaging application format 
into a proprietary messaging format (Msg. FT) and export the translated message over 
TCP/IP. 

20 The CM 205 comprises several modules including: Event Manager 207; format 

converter 210; Messaging System (Mes. Sys.) 220; priority queue (Q) 230 and TCP/IP 
module 240. 

The User, operating an email application program in an off-line mode and desmng to 
send an outgoing message, presses the send button, or its equivalent, and the message is 

25 submitted to tihe outbox. The email application program then indicates to its extensions that a 
new message is waiting in the outbox. Upon receiving this mdication, the Event Manager 
207 calls the Format Converter 210, which reads the new message in MAPI format and 
translates it into the Mes. FT. The Mes. FT is a chain of properties, which, among other 
things, includes the message. The format converter 210 which translates the MAPI message 

30 into the Mes. FT and vice versa, may select part of the properties that are sufficient to 
reconstruct the right message in the other side of the conununication channel. 



Fig. 2a illustrates a block diagram of an exemplary embodiment of a Client Module 
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Mes. Sys. 220 receives the chain of objects of the new converted message, organizes it 
into a complete message and sends the complete message to the queue 230. By using a 
proprietary messaging format, the present invention has the flexibility to be connected to a 
mail client and personal information manager system, other than OUTLOOK, by simply 
modifying the Event Manager 207 and the Format Converter 210, to fit the API of the other 
mail system. 

Queue 230 organizes the messages according to the priority that has been chosen or 
selected by the user. Queue 230 is the buffer between OUTLOOK and the network. 
Transmitting and receiving of the messages are transparent to the user, thus giving the user 
off-line operation with an on-line expraience. 

The output of the queue 230 is transferred to the TCP/IP module 240 that handles the 
communication over TCP/IP from or to OUTLOOK. The TCP/IP module 240 picks a 
complete message from the queue 230 and transfers it over TCP/IP via the configured socket. 
The TCP/IP module 240 also maintains the connection and tries to reconnect to its defined 
socket in case the connection has been broken. 

In the exemplary embodiment of Fig. 2a, the message is then sent out over TCP/IP. 
Alternatively, in the exemplary embodiment of Fig. 2b, the message &om OUTLOOK is sent 
via TCP/IP to a booster unit 260 that translates the TCP/IP buffers into a more efficient 
protocol, manipulates Ifae message to accelerate the communication and sends the 
transformed message via a proprietary tunnel (BST connection) 265 to the GW 130. 

In the other direction, when a message is received from the Exchange Server 175 
(FIG. 1), the TCP/IP module 240 handles the data on a packet basis and transfers it to the 
input section of queue 230. The data from queue 230 is transferred to Mess. Sys. 220. The 
Mess. Sys. 220 gathers the information fi^m the relevant packets mto the whole message and 
transfers it to the format converter 210. The format converter 210 translates the proprietary 
format back to the MAPI format, and the message is then transferred to its destination (e.g. 
the inbox, the calendar etc.). In parallel, the Event Manger 207 sends an mdication to the user 
that the message has arrived at client 110. 

Incoming messages can occur in one of two methods. In one method, a new message 
notification has been sent to the user's mailbox within the Exchange Server 175 and wakes up 
the user agent to start downloadmg the message. In another method, the user presses the 
Send/Receive button on the OUTLOOK menu when the OUTLOOK application is not 
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connected. The Event Manager 207 that waits for this event, sends a refresh message to the 
user agent to instruct the user agent to start download new messages. 

Fig. 3 illustrates a block diagram of an exemplary embodiment of a Domain Module 
(DM) 160 m a Corporate Domain 170. Corporate Domain 170 comprises an Exchange 
5 Server 175 and an exemplary DM 160. 

The DM 160 may be an NT machine, a Window 2000 machine etc., and comprises 
several logical modules including: a TCP/IP module 340, a DM priority queue (Q) 330, 
Dispatcher 350 with its Messagmg System 352, and a plurality of User Agents (UA) 360. 

On the upper side, the DM 160 is connected to an Exchange Server 175 and on the 
10 other side is connected to a plurality of clients 110 via TCP/IP connection 345 over the 
Internet (not shown in Fig. 3). Because OUTLOOK in the client computer 110 is operating in 
off-line mode, the transportation between the CM 200 and the DM 160 is carried by a 
proprietary Transport Provider over the TCP/IP connection 345. 

The TCP/IP logical module 340 handles the incoming data from the remote user, via 
15 the configured socket, on a packet basis, processes them according to the protocol and 
transfers the data to the input section of queue 330. The TCP/IP module 340 also maintains 
the connection and tries to reconnect to its defmed socket in case the connection has been 
broken. 

The data from the input section of queue 330 is grabbed by the Dispatcher Mess. Sys. 
20 352. The Dis, Mess. Sys. 352 pulls the information, organizes it into a message and transfers 
the message to the Dispatcher 350. 

Dispatcher 350 reads tiie envelop of the message and, based on its current dispatching 
list, determines whether the source of the message is a new remote user 110. If the source of 
the message is a new user, the Dispatcher 350 assigns a free User Agent 360 to the new user, 
25 adds this assignment to its dispatching list and submits the message to the selected UA 360. 
If the source of the message is not a new user, the Dispatcher 350, based on the dispatching 
list, transfers the message to the ^propriate UA 360. 

UA 360 represents its assigned user m front of the Exchange Server 175. The UA 360 
performs login and logout m the name of current user of the remote client 110, spoofing the 
30 Exchange Server 175 into operating as though the remote user is connected locally to the 
domain and operating as an interactive user, who receives and transmits OUTLOOK 
messages and mail. 
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A UA 360 comprises of priority queue logical module 363, Mes. Sys. logical module 
320, format converter logical module 310 and Event Manager logical module 307. 

Uploaded messages from the remote user are submitted by the Dispatcher 350 to the 
input section of priority Queue 363 of the UA 360. Messaging System 320 pulls the 
5 information from the input section based on its priorily, organizes the information into a 
message in the proprietary messaging format and transfers it to the Format Converter 310. 
Format Converter 310 translates the proprietary messaging format into MAPI/CDO format 
and transfers the message m MAPI format to the Event Manager 307. 



10 determmes whether the message is a Logm-request or an Inter Personal Messaging (JPM) 
message. If the message is a Login-request, the Event Manager 307 impersonates as the 
remote user and performs a logon sequence to the Exchange Server 175 on behalf of this user. 
The Event Manager 307 uses the credentials of the remote user that have been collected by 
the Event Manager 207 of the CM 200 and initiates a MAPI session in the Exchange Server 

15 175. The operation of the UA Event Manager 307 is described in more detail below. 

Moreover, in some embodiments the: UA Event Manager 307, the Format Converter 
310 and the Mes. Sys. 320 may be combined into a single logical module or into two logical 
modules instead of the three modules of the current exemplary embodiment. 



20 connected to the DM 160, are processed by the appropriate UA 360 and submitted to the 
output section of Priority Queue 330. The output section of the Priority Queue 330 of the 
DM 160, collects the outgoing messages from each UA 360. The outgoing messages, from 
Priority Queue 330, preferably based at least in part on thefr priorily, are pulled and processed 
by TCP/IP logical module 340 and are sent as packets over TCP/IP to the appropriate user of 

25 remote client 110. 

Alternatively, in another exemplary embodiment (not shown in the drawings) a 
booster unit may be used between the TCP/IP logical module 340 and the network. This 
booster unit manipulates the transportation into a more efiGcient protocol, manipulates the 
message to accelerate the communication and sends the transformed message via a 

30 proprietary tunnel (BST connection) to the GW 130. This imit may perform the 
complementary operations of the booster unit 260 in FIG. 2b. 



Upon receiving a new message from the remote user, the Event Manager 307 



Messages from the Exchange Server 175 to the remote users, which are currently 
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As part of the installation process of the CM in its computer, the user is required to 
select one of its on-line OUTLOOK profiles. The user may generate this profile by using the 
Windows Mail Configuration within the control panel. 

Fig. 4a is a flow chart illustratmg one method for implementing an exemplary 
5 embodiment of a CM 205 (FIG- 2a&2b) during the login stage. The OUTLOOK application, 
upon mitiation by the user, prompts tiie user at step 410 to select one of the OUTLOOK 
Profiles, At step 420, if the selected profile is a profile that does not mvoke the present 
invention, the CM 205 is not initiated and processing continues at step 422 where the user 
may use OUTLOOK in its common way of operation. 
10 If at step 420 the selected profile is a profile that invokes the present invention, the 

CM 205, at step 424, starts the Login process with the user. This step includes prompting the 
user with a login dialog box, in which the user is required to enter his credentials (user name, 
password domain name and the Exchange Server name). In one embodiment, the CM 205 
may be configured to take these credentials fi-om the user profile without prompting the user 
15 for the dialog box. 

The user credentials with additional configuration parameters (for example: 
compression attributes, the last synchronization time etc.) are sent over the network to the 
DM 160 (FIG. 1) at step 427, using the TCP connection 250 (FIG. 2a&2b) or via a booster 
system 260 in case that such a system exists. Then the CM 205 is waiting 429 for receiving a 
20 response fi*om DM 160. 

Fig. 4b is a flow chart illustratmg one method for implementing an exemplary 
embodiment of a DM 160 during the login stage. Upon receiving a Login request fi-om a 
remote user, the Dispatcher 350 (FIG. 3) verifies (not shown in the drawing) whether the 
remote user has been assigned a UA 360 (FIG. 3). If the remote user has been assigned a UA 
25 360, the Dispatcher 350 forwards the request to the Expropriate UA 360. If there is no 
assignment yet, at step 430 the Dispatcher 350 determmes whether there is a firee UA. If there 
are no fi-ee UAs, at step 432 the Dispatcher 350 waits until a tune-out expires and then 
rechecks for a fi-ee UA at step 430 again. If there is a fi-ee UA 360, at step 434 the Dispatcher 
350 assigns the client to the UA 360, updates its assignment table and forwards the call to the 
30 selected UA 360. 

Upon receiving the Login-request, at step 440 the Event Manager 307 of the selected 
UA 360 determines whether it is the first Login-request of this user 110. If this is not the first 
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Login- request, at step 448 the Event Manager 307 (FIG. 3) updates the connection 
parameters and processing continues at step 456 and retrieves new mail. 

However, if it is the first Login-request of a new user 110 (FIG. 1), processing 
continues at step 442 where the selected UA 360 gets the current client's parameters and 
5 starts the impersonation process at step 444. During tiie impersonation process, the UA 360 
perfonns an NT login to the domain 170, and unpersonates ttie remote user 110 by using the 
client credentials. The UA 360 then creates an OUTLOOK profile for this new client, on the 
machine on which the DM 160 runs, pretending that it is tiie remote client and at step 446, 
starts a MAPI session to the Exchange Server. 
10 At step 450, if the credentials of the user are valid and the login succeeds, at step 454 

Ae UA 360 sends a Login-success message to the CM 205 and the CM 205 processing 
continues at point B in Fig. 4a. In parallel, the UA 360 processing continues at step 456 to 
synchronizes the mailbox. 

At step 450, if the credentials of the user are not valid and the login fails, the UA 360 
15 enters the login fail process at step 452 which sends a Login-fail message to the CM 205 and 
causes the CM 205 to continue processing at point B in Fig. 4a. Then, the UA 360 provides 
notice to the Dispatcher 350 about the disconnection and enters into a free position. The 
Dispatcher 350 updates its assignment table by removing this assignment. 

At step 456 the UA 360 retrieves all new messages, which have arrived to the user's 
20 mailbox (within the exchange server) between the last login and the current login, and sends 
these messages to the remote client 110 via the CM 205. Then at step 458, the UA 360 
registers itself for new message notification within the user's mailbox. 

From this point forward, as long as there is a valid connection between the client 110 
and flie DM 160, the new messages will be automatically downloaded to the usw's off-line 
25 mailbox tiirough the DM 160 and CM 205 (FIG. 2a&2b). 

Returning now to the operation of the CM 205, Fig. 4a point B, upon receiving the 
response for the Login-request, at step 470 tiie CM 205 determines whether the login has been 
successful. If the login has been successful, at step 474 the CM 205 waits for the next event, 
which may be incoming mails tcom the Exchange Servw or outgoing messages fiom the user 
30 110. If the login fails, the CM 205 sends 478 a Lo^-fail indication to tiie user 110 and 
processing continues at step 424 where the CM 205 prompt the user to logui again. 
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Fig. 5 illustrates a method implemented by an exemplary embodiment of a CM 205 
during the on going operation after the login stage. Initially, the CM 205 is waiting for a 
notification that an event has occurred. Upon receivmg an event notification, at step 510 the 
CM 205 determines whether the event arrived 520 fi-om the OUTLOOK outbox or fi-om 540 

5 the TCP/IP connection. 

If the event arrives firom tfie OUTLOOK outbox, which means that the user has sent a 
new message, processing continues at step 522. The new message may be mail, calendar, 
task etc. At step 522, the CM 205 grabs the message firom the outbox and pushes it via the 
chain comprising the Format Converter 210, the Mes. Sys. 220, the output section of priority 

10 queue 230 and the TCP/IP module 240 and at step 530 sends the message over the network as 
described above in conjunction with Fig. 2a. The CM 205 then returns to step 510 to wait for 
the next event. 

If the event arrives fi-om the TCP/IP connection indicating that new message arrives 
from DM 160 (FIG. 1), processing continues at step 542. The message may be a mail, 

15 calendar, task etc. message. At step 542, the CM 205 grabs the message via the chain as 
described above, and at step 544 determines the type of the message. If the type of the 
message 560 is mail or calendar, at step 562 the CM 205 pushes the message into the inbox of 
the remote client 110 and at step 564, sends an indication to the user. Then the CM 205 
returns to step 510 and waits for the next event. 

20 If the type of the message is an error message 570, at step 576 the CM tries to 

reconnect again by returning to step 424 in FIG 4a and continues firom there. If the type of 
the message is login feedback 550 fi-om the DM 160, at step 552 the CM 205 performs the 
part of the process, which is described above in conjunction to Fig. 4a, from point B. 

Fig- 6 illustrates one method for implementing an exemplary embodiment of a UA 

25 360 (FIG. 3) during the on going operation, after the login stage. Initially, UA 360 is waiting 
for an event to occur. Upon receiving notification that an event has occurred, at step 610 the 
UA 360 determines whether the event arrived from the Exchange Server 175 (FIG. 1) (step 
620) or firom the Dispatcher 350 (FIG. 3) (step 640). 

If the event 620 arrives from the Exchange Server 175, it means that the client 110 has 

30 received a new message. The new message may be mail, calendar etc. At step 622, the UA 
360 grabs the message from the inbox of the relevant client 110 in the Exchange Server 175, 
and pushes it via the chain comprising the Format Converter 310 (FIG. 3), the Mes. Sys. 320 



wo 03/058372 



PCT/IL03/00014 



# 



10 



15 



20 



25 



(FIG. 3), the output section of priority queue 330 and the TCP/IP module 340 (FIG. 3), and at 
step 630 sends the message over the network as described above in conjunction with Fig. 3. 
Then, the UA 360 returns to step 610 and waits for the next event 

If the event 640 arrives fix)m the Dispatcher 350, it means that the client has sent this 
new message. The message may be a mail, calendar, login request etc. At step 542, the UA 
360 grabs the message via the chain as described above and at step 644 determines the type of 
the messfi^e. If the type of the messc^e is mail or calendar or etc, 660, then at step 662 the 
UA 360 submits it into tiie outbox in the Exchange Server 175 associated with the user 110. 
The Exchange Server 175 (FIG. 1) takes responsibility to deliver flie message to its 
destination. 

If the type of the message is a disconnection message 650, then the UA 360 closes the 
MAPI session wilii the Exchange Server 175 and clears up tiote allocated resources. Then the 
UA 360 provides notice to tiie Dispatcher 350 that the connection is broken and waits for new 
assignment. 

If the type of the message is Login-request 680 from the CM 205, then at step 682 tiie 
UA 360 performs 682 the part of the login process, which is described above, in conjunction 
to Fig. 4b. At the end of the login process, the UA 360 returns to step 610 and waits for the 
next event. 

Fig. 7 illustrates one method for implementing an exemplary embodiment of a UA 
360 during the Logoff stage. This routine is initiated upon receiving a disconnection 
indication 720 from the TCP/IP module 340. Otherwise the UA 360 continues in its on going 
operation as described above in conjunction to Fig. 6. Upon receiving a disconnection 
indication 720, the UA 360 starts several operations for terminating the on-line operation 
within the Exchange Server. First of all, at step 725 the UA 360 unregisters itself from event 
notifications that occur in the mailbox at the Exchange Server 175. Then at step 730, the UA 
360 closes the MAPI session within the Exchange Server 175. Upon terminating the logoff 
process within the Exchange Server 175, at step 750 the UA 360 notifies the Dispatcher 350 
that it is free agam and at step 760 waits for the next assignment. 

In the description and claims of the present application, each of the verbs, "comprise" 
"include" and *liave", and conjugates thereof, are used to indicate that the object or objects of 
the verb are not necessarily a complete listing of members, components, elements or parts of 
the subject or subjects of the verb. 
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The present invention has been described using detailed descriptions of embodiments 
thereof that are provided by way of example and are not intended to limit the scope of the 
invention. The described embodknents comprise different features, not all of which are 
required in all embodiments of the invention. Some embodiments of the present invention 
5 utilize only some of the features or possible combinations of the features. Variations of 
embodiments of the present invention that are described and embodiments of the present 
invention comprising different combinations of features noted in the described embodiments 
will occxu" to persons of the art. The scope of the invention is limited only by the following 
claims. 
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CLAIMS 

What is claimed is: 

1. A system for enabling the exchange of data between at least one remote user 
having a client application program running in an off-line mode and a server 

5 communicatively coupled to the application program over a network, said system comprising: 
a client logical module adapted to: 
receive user credentials; 

detect the generation of an outgoing message generated through the 

application program; 

1 0 transfer the outgoing message over the network to a domain module; 

receive incoming messages from the domain module; and 
transfer the incoming messages to the application program while the 
application program is operating in an off-line mode; 

a domain module commimicatively coupled to the client logical module and 
IS opemting in association with the server, said domain module being adapted to: 

impersonate the remote user, thereby appearing to the server as though 
the application program is connected directly to the server in an on-line mode; 

receive outgoing messages from the client logical module; 
transfer the outgoing messages to the server; 
20 receive a message from the server; and 

provide the received messages to the client logical module in the 

remote client. 

2. The system of claim 1, wherein the network is a TCP/IP network. 

3. The system of claim 1, wherein the application program is an email application 
25 program. 

4. The system of claim 3, wherein the email application program is OUTLOOK. 

5. The system of claim 1, wherein the domain module is further adapted to 
impersonate the remote user by performing a login procedure on behalf of the implication 
program, thereby opening a communication session between the client logical module and the 

30 server. 

6. The system of claim 4, wherein the communication session between the the 
client logical module and the server is a MAPI session. 
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7. A method for exchanging data between a plurality of remote clients, each 
remote client running an email application program in an off-line mode, and a server in a 
domain which is connected to the remote clients over a TCP/IP network, said method 
comprising the steps of: 

5 sending a login request from at least one of the plurality of remote clients to a 

domain module; 

in response to receiving the login request, said domain module impersonating 
the remote client by logging into the server serving the remote client; 

opening a communication session between the remote client and the server; 

10 and 

transferring messages between the remote client and the server via the domain 
module, whereby the email application program appears to operate as though it is on-line with 
the server. 

8. The method of claim 7, wherem the remote client includes a client logical 
15 module, and the step of sendhoig the login request further comprises the steps of: 

receiving credentials from the remote client; and 

the client logical module forwarding the login request with flie credentials to 
the domain module. 

9. The method of claim 7, wherein the server is an exchange server. 

20 10. The method of claim 7, wherein the communication between the domain 

module and the server is using MAPI. 

11. A system for enhancing perceived throughput between a plurality of remote 

clients running an OUTLOOK application and an exchange server in a domain which is 

coimected to the remote clients over a TCP/IP network, said system comprising: 
25 a client logical module for each remote client, the client logical modules being 

adapted to: 

receive credentials for a user of tiie remote client; 

receive outgoing messages from a remote client outbox and to transfer 
the outgoing messages over the TCP/IP network to a domain module; and 
30 receive messages from the domain module and transfer them to a 

remote client inbox m the OUTLOOK application while the OUTLOOK 2^)plication is 
operating in an off-line mode; 
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a domain module, which is connected between said TCP/IP network and the 



domain, for each said plurality of remote clients, said domain module being adapted to: 



remote client, whereby using said system allows the delivery of messages between the 
plurality of remote clients and the exchange server in an off-line mode of operation of the 
OUTLOOK application without having to modify the exchange server. 

12. A method for exchanging data between a remote client running an application 
program in an off-line mode, and a server operating within a domain to which the remote 
client is communicatively coupled, said method comprismg the steps of: 

receiving credentials for a user of the remote client; 

detecting a message from the application program that is directed to the 

server; 

reformatting the message from MAPI format to a proprietary format; 
transferring the message to the server over a communication channel; 
detecting the reception of the message at the domain; 
reformatting the reformatted message from the proprietary format to 
the MAPI format to create a MAPI message; and 

providing the MAPI message to the server. 

13. The method of claun 12, further comprising the steps of: 

sending a login request to the server; 

m response to receiving the login request, emulating the actions that 
would normally be taken by the application program to login to the server; and 



impersonate the remote client by spoofing the exchange server to 
operate as though the remote client is connected directly to the domain; 

login into the exchange server using the credentials of the user of the 

remote client; 



open a MAPI session for the remote client; 

receive messages from the client module of the remote client; 

transfer OUTLOOK messages to the exchange server; 

receive messages destined to a remote client from the exchange server; 
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opening a MAPI session between the application program and the 
exchange server, whereby the application program appears to operate as though it is on-line 
with the server. 

14. The method of claun 12, wherein a MAPI session exists between the 
5 application program running on the remote client and the server to &cilitate communication 

of messages, further comprising the steps of: 

sending a discoimect request to the server; 

in response to receivmg the disconnect request, emulating the actions 
that would normally be taken by the application program to logoff the server; and 
10 closing the MAPI session between the ^application program and the 

exchange server, 

15. The method of claun 12, fiirther comprismg the steps of: 

detectuig a message from the server that is directed to the application 

program; 

1 5 reformatting the message from MAPI format to a proprietary format; 

transferrmg the message to the application program over a 
communication channel; 

detecting the reception of the message at the remote client; 

reformatting the reformatted message from the proprietary format to 
20 the MAPI format to create a MAPI message; and 

providing the MAPI message to the application program. 

16. The method of claim 15, wherein the application program is an email 
application program and the step of providing the MAPI message to the application program 
comprises placing the MAPI message into the inbox of the email application program. 

25 17, The method of claim 12, wherein the application program is an email 

application program and the step of detecting a message from the explication program 
comprises detecting a new message in the outbox of the email application program. 

18. The method of claun 17, wherein tiie email application program is 
OUTLOOK, ftirther comprising the steps of: 
30 receiving a profile selection, the profile selection being associated with 

enabling the off-line operation; and 

enabling the off-line operation in conjunction with the profile selection. 
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19. The method of claim 17, wherein the email application program is 
OUTLOOK, further comprising the steps of: 

receiving a profile selection, the profile selection not being associated with 
enabling the oflP-line operation; and 
5 disablmg the step of detecting a message from the application program that is 

directed to the server. 
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Fig. 5 
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